Columbia Kermit/kermit.zip/newsgroups/misc.19950726-19950929/[e-mail]_Sat Jul 29 21:47:33 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA09071
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Thu, 3 Aug 1995 11:10:23 -0400
Received: by apakabar.cc.columbia.edu id AA28719
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 3 Aug 1995 11:10:21 -0400
Path: news.columbia.edu!panix!news.mathworks.com!usenet.eel.ufl.edu!spool.mu.edu!agate!news.mindlink.net!vanbc.wimsey.com!ddsw1!news.mcs.net!not-for-mail
From: [e-mail] (Leslie Mikesell)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit download from CompuServe.. best setup??
Date: 29 Jul 1995 16:47:33 -0500
Organization: /usr/lib/news/organi[sz]ation
Lines: 51
Message-Id: <3vea9l$[e-mail]>
References: <3uidtu$[e-mail]> <[e-mail]> <[e-mail]> <3var29$[e-mail]>
Nntp-Posting-Host: venus.mcs.com
Apparently-To: [e-mail]

In article <3var29$[e-mail]>,
Frank da Cruz <[e-mail]> wrote:
>In other words, binary mode (= "No Presentation Layer")
>works for all files only when:
>
> (a) The two systems have the same text-file format (e.g. stream LF,
>     stream CRLF, stream CR), and then (usually) only when the files
>     are stream, rather than record oriented, and:
>
> (b) Character-set conversion is not required.
>
>Therefore, when conditions (a) and (b) are not met, one must pick text or
>binary mode for each file transfer in order to avoid corruption.  And that
>implies that, for convenience, one must also have a default mode to be
>used in the absence of a specific directive from the user.  The rub, of
>course, is that any given default will not fit every file transfer.

But, since kermits exchange some initialization information before
the transfer, it would be quite possible for them to know when
case (a) applies.  All you would have to to is assign a code for
each of the types of conversions that kermit does when going
from local to canonical text (probably 4 common ones...) and send
this as part of the initialization codes.  If the remote and local
codes are identical, skip the text transformations and do everything
in binary mode unless you have been told to do character-set conversion.
This would take care of the most common case these days where you
are transferring among like systems, and the fall-back for kermits
that don't send a code or send an unknown code would be to use the
current behaviour with a warning the BINARY/TEXT should be set explicitly.
How many calls do you get about this problem?  How many people give up
on kermit because their files end up corrupted?  It would also make
sense to give a warning when one end has binary mode set and the
other has text mode.

It's really too bad that no one has established a standard for binary
storage of text so it could be labeled by the originating system as
to the character set and line/record ending conventions so files
could be moved around without the transport having to do the conversions
(i.e. by network file services, diskettes, tape, etc.).  MIME comes
close and gets character sets right, but it doesn't really address the
local storage conventions for text, so you still can't arbitrarily
move files around without twiddling at the transport layer.

>  WHEREAS nobody, not even the most inexperienced user, transfers any type
>  of file except ZIP and GIF and JPEG any more, and...

Unfortunately, GIF and JPEG files are more portable than text these
days.

Les Mikesell
  [e-mail]